An Adaptive Synchronization Protocol for Parallel Discrete Event Simulation

Simulation, especially discrete event simulation (DES), is used in a variety of disciplines where numerical methods are difficult or impossible to apply. One problem with this method is that a sufficiently detailed simulation may take hours or days to execute, and multiple runs may be needed in order to generate the desired results. Parallel discrete event simulation (PDES) has been explored for many years as a method to decrease the time taken to execute a simulation. Many protocols have been developed which work well for particular types of simulations, but perform poorly when used for other types of simulations. Often it is difficult to know a priori whether a particular protocol is appropriate for a given problem. In this work, an adaptive synchronization method (ASM) is developed which works well on an entire spectrum of problems. The ASM determines, using an artificial neural network (ANN), the likelihood that a particular event is safe to process. 1 Parallel discrete event simulation Simulation, especially discrete event simulation (DES), is used in a variety of disciplines where numerical methods are difficult or impossible to apply. One problem with this method is that a sufficiently detailed simulation may take hours or days to execute, and multiple runs may be needed in order to generate the desired results. In general there are three ways to speed up the execution of a DES: the algorithms in the simulation can be improved (both in the model and in the simulation framework), the simulation can be executed on a faster machine, and the simulation can be run in parallel on several processors. The last method, parallel discrete event simulation (PDES), is the focus of this research. The typical method to parallelize a discrete event simulation is to divide the model that is being simulated into separate sub-models, called physical processes. For example, in a manufacturing plant simulation each machine could be considered a separate physical process. Each physical process is then simulated by a logical process (LP). An LP communicates with another LP by transmitting a message that contains an event. An event consists of an execution time (the timestamp), which indicates the simulation time at which the event is to be executed on the destination LP, the model-specific actions to be performed, and the source (i.e., transmitting) and the destination (i.e., receiving) LPs. It is possible for the source LP and destination LP to be the same. When an LP receives a message, the event that is contained in the message is scheduled for execution. The source LP is said to have generated the event that is scheduled on the destination LP. Each LP maintains its own independant simulation clock, called the local virtual time (LVT). The LVT is the timestamp of the last event that has been executed. There is also a global virtual time (GVT), which is defined as the minimum of all the LVTs and any messages in transit in the simulation. The GVT records the global progress of the simulation. The behavior of a PDES is influenced by many factors, including the model that is being simulated, the hardware on which the simulation is executing, the communication network that connects the processors, and the simulation framework (the infrastructure upon which the model is built). The situation becomes even more complex when the simulation is run on a heterogeneous collection of machines with varying computation power. Reynolds [14] has identified nine design variables that can be used to describe the spectrum of PDES synchronization. The two which are most directly related to this work are aggressiveness and risk. Aggressiveness is the willingness of an LP to process an event that may turn out to be incorrect. An LP that never executes events out of timestamp order has zero aggressiveness. An LP that allows events to be executed out of order, but later corrects the errors that result, is aggressive. Risk is the willingness of an LP to transmit messages that later may have to be retracted because an event was processed incorrectly (i.e., out of order). Nonzero risk implies that the simulation has some method to undo the effects of erroneous messages (e.g., anti-messages). 1.1 Conservative PDES The conservative simulation protocol [3, 2] prevents out of order execution of events. Using the terminology of Reynolds [14], it is non-aggressive and non-risky. An event is not executed by an LP unless it can be guaranteed that no other event with a smaller timestamp (a straggler) will be received. Such an event is called a safe event. If there are no known safe events, the LP will block until a safe event becomes available. A safe event can become available in one of two ways: a new event is received and determined to be safe, or a previously received event is determined to be safe, usually because an event was received from another LP. In general, messages from one LP to another must be sent in increasing timestamp order. A message from LP1 to LP2 with timestamp t is a guarantee by LP1 to LP2 that LP1 will not send another message with a timestamp less than t. In this way, an LP can determine if an event is safe to process. If an LP has received a message from every other LP with a timestamp larger that the timestamp of the event in question, the event is safe. To prevent deadlocks, LPs send out null messages, messages with no corresponding event, only a timestamp. These messages simply serve to update the minimum timestamp on messages from a particular LP.